Description: When in use path longer than 200 characters or shorter path with long file name semaphore files are not deleted when LO applications are closed. Ex. .~lock.- filename -.odt# this file with 111 byte lenght remain in the original document directory when, just for this example, Writer has been closed. Steps to Reproduce: 1.create a long path (> 150/200 characters) 2.Create a document inside this path 3.Close, re-open and re-close this document 4.Look inside the folder for the presence of a .~lock.- filename -.ext# file Actual Results: 1.create a long path ex Drive:\data\Enterprise name\customers\architecture, constructions, buildings and materials\United States of America\Missouri\2024\customer ID - Customer name\project ID - Project name\documentation 2.Create a document inside this path 3.Close, re-open and re-close this document 4.Look inside the folder for the presence of a .~lock.- filename -.ext# file Expected Results: Expecting that the temporary semaphore file was deleted at when the program close Reproducible: Always User Profile Reset: No Additional Info: Leave a temporary semaphore file with name similar to: .~lock.- filename -.ext# for every time a document has been opened from a folder with a long path. Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 2; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win Locale: it-IT (it_IT); UI: en-US Calc: CL threaded
Are you able to deleted it with the file explorer, outside LibreOffice? https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry
The files can be deleted in the usual way without making any particular maneuver. The strange thing is that if there is a path problem also the creation and the modification of a document could be affected but here the problem is only with the temporary lock/semaphore files.
Can you test if there is a length limit, by changing the file name to a new shorter one, or by modifying the length of the folder name?
in this scenario (259 total characters between drive letter, :, paths, filename, . and extension) everything is ok and the lock/samaphore file is removed: C:\Users\Username\Documents\llllllll\lllllllllll\lllllllllllllllllllllllllllllllllllllllll\llllllllllllllllllllllllllllllllllllllllllllllllllll\llllllllllllllllllllllll\llllllllllllllllllllllllllllllllllllllllllllllllll\lllllllllllllllllllllllllllllllllll.odt in this scenario (just one more character, 260, in the last level directory name where the document is present) the lock/samaphore remain in place after closing LO Writer: C:\Users\Username\Documents\llllllll\lllllllllll\lllllllllllllllllllllllllllllllllllllllll\llllllllllllllllllllllllllllllllllllllllllllllllllll\llllllllllllllllllllllll\lllllllllllllllllllllllllllllllllllllllllllllllllll\lllllllllllllllllllllllllllllllllll.odt But here documents with the same name lenght, or more, can be created and updated but always the lock files remains.
[Automated Action] NeedInfo-To-Unconfirmed
I don't reproduce this with Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 2; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded For testing, Windows does not allow you to create file names that exceed the 259 limit when inside a long path, but you can save a file from LibreOffice with a name length of your choosing. Recently there were Windows path fixes like bug 157254 and bug 157820. Do you use a normal or a portable installation?
Oh, and a PowerShell tip for creating that long path: New-Item -ItemType Directory 'z:\data\Enterprise name\customers\architecture, constructions, buildings and materials\United States of America\Missouri\2024\customer ID - Customer name\project ID - Project name\documentation'
(In reply to Buovjaga from comment #6) > I don't reproduce this with > > Version: 7.6.4.1 (X86_64) / LibreOffice Community > Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 > CPU threads: 2; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: > win > Locale: en-US (en_US); UI: en-US > Calc: threaded > > For testing, Windows does not allow you to create file names that exceed the > 259 limit when inside a long path, but you can save a file from LibreOffice > with a name length of your choosing. > > Recently there were Windows path fixes like bug 157254 and bug 157820. Do > you use a normal or a portable installation? Normal app, not portable. It would be very nice if LO can support \\?\ unicode absolute path which heve not the 256 characters limitation: https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry But now the bug report is about the correct creation of lockfile in a near 256 characters path+filename scenario (so LO can handle it) but not its removal when a document is closed (when LO had already proved to be able to handle it).
You don't happen to have any anti-virus software running that could meddle with the lock files?
(In reply to Buovjaga from comment #9) > You don't happen to have any anti-virus software running that could meddle > with the lock files? No AV at all. The lock files Ex. .~lock.2023-12-21 - File not removed demonstration.odt# are normally created with the exact filename of the document but then they must be manually removed from the directory because closing LO application (in this case Writer) the temporary files remains in the folder.
(In reply to edg from comment #8) > > Recently there were Windows path fixes like ... bug 157820. ... > > It would be very nice if LO can support \\?\ unicode absolute path which > heve not the 256 characters limitation Please re-check the bug 157820 that Buovjaga mentioned. Let me try to repro the problem that you describe.
(In reply to edg from comment #4) > in this scenario (just one more character, 260, in the last level directory > name where the document is present) the lock/samaphore remain in place after > closing LO Writer: > > C: > \Users\Username\Documents\llllllll\lllllllllll\llllllllllllllllllllllllllllll > lllllllllll\llllllllllllllllllllllllllllllllllllllllllllllllllll\llllllllllll > llllllllllll\lllllllllllllllllllllllllllllllllllllllllllllllllll\llllllllllll > lllllllllllllllllllllll.odt > > But here documents with the same name lenght, or more, can be created and > updated but always the lock files remains. I have tested this - the only different character was drive letter D:, so the path looked like D:\Users\Username\Documents\llllllll\lllllllllll\lllllllllllllllllllllllllllllllllllllllll\llllllllllllllllllllllllllllllllllllllllllllllllllll\llllllllllllllllllllllll\lllllllllllllllllllllllllllllllllllllllllllllllllll\lllllllllllllllllllllllllllllllllll.odt Opening the file with Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 24; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win Locale: ru-RU (en_US); UI: en-US Calc: CL threaded created the expected lockfile in the same directory (.~lock.lllllllllllllllllllllllllllllllllll.odt#); and that file was successfully removed, when I close Writer. I also tested with Version: 7.5.0.3 (X86_64) / LibreOffice Community Build ID: c21113d003cd3efa8c53188764377a8272d9d6de CPU threads: 24; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded In that older version, it also worked fine. So you likely need to make sure you didn't miss some small detail - e.g., how the file was opened (I tried double-click in Explorer to start associated Writer; opening from inside LibreOffice using File->Open; and also from the LibreOffice's Recent File list). Possibly a screencast could also help.
Probably the OS work in different ways. Maybe in your system exist the registry value: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled (Type: REG_DWORD) and is set to 1 In all my cases (3x Win 7) the problem still occour with LO 7.6.4.1 opening the document from Explorer (or other system shell like Total Commander) and opening the document from Writer.
(In reply to edg from comment #13) On my test system, LongPathsEnabled exists and is 0 (zero).
Just in case: the path shown as problematic in comment 4 (and the one that I used in comment 12) has total length of 260 characters (not including trailing zero). This is already 1 character larger than the old FS limit (which is 260 characters *including* trailing zero). But I was thinking, that maybe the "Username" part of the path was written arbitrarily, in place of a different-length actual folder name. So I also tried with significantly longer name in this place, too; it also worked here. Indeed, something is different. Unfortunately, I have no idea what; so it's up to you (or anyone who can also repro), to try to nail down the repro steps to the crucial piece.
What is your file system BTW? Is it NTFS? Or maybe it is, say, ExFAT, by chance?
(In reply to Mike Kaganski from comment #16) > What is your file system BTW? Is it NTFS? Or maybe it is, say, ExFAT, by > chance? The file system is always NTFS. The "username" part of the path was obviously replaced but adjusting the last folder name accordingly so in the end the total path+filename is correctly dimensioned and is the minimum lenght that initiate to show the problem. 1 byte less and everything is ok.
I can't reproduce it in GNU/Linux, btrfs FS: Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: 60(Build:1) CPU threads: 16; OS: Linux 6.6; UI render: default; VCL: kf5 (cairo+xcb) Locale: es-ES (es_ES.UTF-8); UI: es-ES Calc: threaded I did create a directory like this for the tests: raul@mordor:/tmp/test/asdpfioqfjhpiouashdfpuiewfweqpuifewpuroigñfuwerpioghjwerpiogujewrpogihjeuoptrghepouwigheoipwrghjweporigfjuqeproigfjuheqwrpuigfjhrewpioqǵfjuwerpoifujghweproiugfjhewrpiohgjwerpoighjriopaugfjherpiowghj$ ls -la total 12 drwxr-xr-x 2 raul raul 60 dic 29 14:21 . drwxr-xr-x 3 raul raul 60 dic 29 14:20 .. -rw-r--r-- 1 raul raul 9485 dic 29 14:21 test.odt